bors [Thu, 3 May 2018 18:19:51 +0000 (18:19 +0000)]
Auto merge of #5473 - ehuss:autobin-warning, r=alexcrichton
Address autobins warning.
Removes the large warning displayed if you build Cargo with itself (but adds a warning if you build with an older Cargo). Not sure which approach you prefer to address it, or if you want to do this later.
bors [Thu, 3 May 2018 17:03:06 +0000 (17:03 +0000)]
Auto merge of #5470 - alexcrichton:hopeful-fix, r=matklad
Attmept to fix a spurious failure on AppVeyor
I *think* the issue is that `link.exe` is generating debuginfo in the background
which keeps the file open and prevents us from deleting it, but hopefully by
disabling debug information we'll either be able to confirm or deny this
hypothesis.
Alex Crichton [Thu, 3 May 2018 15:01:25 +0000 (08:01 -0700)]
Attmept to fix a spurious failure on AppVeyor
I *think* the issue is that `link.exe` is generating debuginfo in the background
which keeps the file open and prevents us from deleting it, but hopefully by
disabling debug information we'll either be able to confirm or deny this
hypothesis.
bors [Thu, 3 May 2018 15:31:44 +0000 (15:31 +0000)]
Auto merge of #5468 - matklad:aliases, r=alexcrichton
Tweak handling of aliases
Previously, `execute_subcommand` was called recursively, and each call
would `.configure` the `config` again. It worked, but seemed rather
fragile.
This commit handles aliases more explicitly, ensures that `.configure`
is called once and, as a bonus, adds a warning for when an alias is
shadowed by the built in.
Aleksey Kladov [Thu, 3 May 2018 10:50:05 +0000 (13:50 +0300)]
Make alias handling more straightforward
Previously, `execute_subcommand` was called recursively, and each call
would `.configure` the `config` again. It worked, but seemed rather
fragile.
This commit handles aliases more explicitly, ensures that `.configure`
is called once and, as a bonus, adds a warning for when an alias is
shadowed by the built in.
Nick Cameron [Thu, 3 May 2018 08:23:49 +0000 (20:23 +1200)]
Revert part to #5393
Commit 0b530c30867da26a4b59146f490c9f1d5377c20a (which this commit mostly reverts) did some refactoring around the `target_dir` function. However, it introduced a bug because it meant that where `CARGO_TARGET_DIR` was specified but `--target-dir` was not, the value from `CARGO_TARGET_DIR` was ignored.
bors [Wed, 2 May 2018 23:52:15 +0000 (23:52 +0000)]
Auto merge of #5462 - matklad:install-releases, r=alexcrichton
Don't install pre-releases by default
Currently, `cargo install` will try to install a pre-release version, if available (try `cargo install rand`). This happens because we use `VersionReq::any`, if no version is specified, and that matches pre-releases. The fix is to use `*`, which is different from `any`.
This needs to be done in `cargo install`, and not directly in `parse_no_deprecated`, the latter would be wrong, as demonstrated by a new test with patch.
bors [Wed, 2 May 2018 17:17:27 +0000 (17:17 +0000)]
Auto merge of #5456 - LukasKalbertodt:patch-1, r=matklad
Show elapsed time in minutes if >= 60 secs
In large projects with long compile times, seeing "428.65 secs" isn't as clear to humans as seeing the number of minutes (and seconds).
**Old**:
```
Finished dev [unoptimized + debuginfo] target(s) in 2.23 secs
Finished dev [unoptimized + debuginfo] target(s) in 63.94 secs
Finished dev [unoptimized + debuginfo] target(s) in 428.65 secs
```
**New**:
```
Finished dev [unoptimized + debuginfo] target(s) in 2.23s
Finished dev [unoptimized + debuginfo] target(s) in 1m 3.94s
Finished dev [unoptimized + debuginfo] target(s) in 7m 8.65s
```
Note that I also changed `secs` to `s`, because `7 mins 8.65 secs` and `7m 8.65 secs` both look strange IMO. But if you disagree and you'd prefer `secs`, just tell me and I'll change it.
I *didn't* add a check for `secs >= 3600` to print the time in hours. I *hope* this is not necessary...
bors [Wed, 2 May 2018 14:15:23 +0000 (14:15 +0000)]
Auto merge of #5432 - djc:split-context, r=alexcrichton
Split Context into two types
@matklad here's the crazy attempt to make the `Context` situation slightly more sane. It basically splits all of the stuff that is immutable over the lifetime of the compilation from the stuff that's initialized empty. The latter is now stored in a type which I have provisionally called `BuildProgress` -- feel free to bikeshed about the name (I came up with `BuildData` as another alternative). It stores a reference to the `Context` to make things easier for now, we might want to change that down the line.
IMO this is a pretty good improvement, which clarifies the design quite a bit.
@alexcrichton you'll probably want to review this, too.
bors [Tue, 1 May 2018 18:32:06 +0000 (18:32 +0000)]
Auto merge of #5451 - DarkDrek:add_doc_clean, r=alexcrichton
Add cargo clean --doc
Implements #5449.
It only removes the doc directory and therefore keeps all other build artifacts intact.
When `--doc` is used all other options are ignored.
My test case is mostly copy&paste from `clean_release` so maybe the `.toml`s can be simplified.
Auto merge of #5300 - djc:namespaced-features, r=alexcrichton
Introduction of namespaced features (see #1286)
I think this basically covers all of the plans from #1286, although it still needs a bunch of tests and documentation updates. Submitting this PR to get some early feedback on the direction.
As discussed at https://github.com/rust-lang/cargo/issues/5364, the new behavior unfortunately causes real-life breakage, so we have to revert it.
This is kinda sad, this is a part of the larger issue with feature selection, which, at the moment, has a behavior which I would classify (loosely speaking) as unsound:
* `cargo build -p foo` and `cargo build -p foo -p bar` might produce different artifacts for `foo` ([repro](https://github.com/matklad/workspace-vs-feaures))
* `cargo build -p foo` might produce different artifacts, depending on cwd ([repro](https://github.com/matklad/features-cwd))
The new feature behavior specifically addressed the second point.
It is unclear what we could do with this... One option, instead of flatly erroring out, as the revreted commit does, is to print a warning, but change the set of activated features. It will still be a breaking change, but it at least has a chance of working by accident.
Take feature namespace into account while building summary (fixes #1286)
Here's an attempt at a table to cover the different cases:
Feature
Old (must be in features table)
Continue
Namespaced (might be stray value)
In features table: Check that Crate dependency is in the list
-> Non-optional dependency: Bail [PREVIOUSLY: bailed for non-optional dependency]
-> Optional dependency: Insert feature of this name
-> Else: Bail [PREVIOUSLY: bailed for unknown dependency or feature]
Crate
Old (might be stray value)
Non-optional dependency: Bail
No dependency found: Bail
Namespaced
Non-optional dependency: Bail
No dependency found: Bail
CrateFeature
Old
No dependency found: Bail
Namespaced
No dependency found: Bail
Auto merge of #5384 - ehuss:profile-override, r=matklad
Profile Overrides (RFC #2282 Part 1)
Profile Overrides (RFC #2282 Part 1)
WIP: Putting this up before I dig into writing tests, but should be mostly complete. I also have a variety of questions below.
This implements the ability to override profiles for dependencies and build scripts. This includes a general rework of how profiles work internally. Closes #5298.
Profile overrides are available with `profile-overrides` set in `cargo-features` in the manifest.
Part 2 is to implement profiles in config files (to be in a separate PR).
General overview of changes:
- `Profiles` moved to `core/profiles.rs`. All profile selection is centralized there.
- Removed Profile flags `test`, `doc`, `run_custom_build`, and `check`.
- Removed `Profile` from `Unit` and replaced it with two enums: `CompileMode` and `ProfileFor`. This is the minimum information needed to compute profiles at a later stage.
- Also removed `rustc_args`/`rustdoc_args` from `Profile` and place them in `Context`. This is currently not very elegant because it is a special case, but it works. An alternate solution I considered was to leave them in the `Profile` and add a special uber-override layer. Let me know if you think it should change.
- Did some general cleanup in `generate_targets`.
## Misc Fixes
- `cargo check` now honors the `--release` flag. Fixes #5218.
- `cargo build --test` will set `panic` correctly for dependences. Fixes #5369.
- `cargo check --tests` will no longer include bins twice (once as a normal check, once as a `--test` check). It only does `--test` check now.
- Similarly, `cargo check --test name` no longer implicitly checks bins.
- Examples are no longer considered a "test". (See #5397). Consequences:
- `cargo test` will continue to build examples as a regular build (no change).
- `cargo test --tests` will no longer build examples at all.
- `cargo test --all-targets` will no longer build examples as tests, but instead build them as a regular build (now matches `cargo test` behavior).
- `cargo check --all-targets` will no longer check examples twice (once as
normal, once as `--test`). It now only checks it once as a normal
target.
## Questions
- Thumbs up/down on the general approach?
- The method to detect if a package is a member of a workspace should probably be redone. I'm uncertain of the best approach. Maybe `Workspace.members` could be a set?
- `Hash` and `PartialEq` are implemented manually for `Profile` only to avoid matching on the `name` field. The `name` field is only there for debug purposes. Is it worth it to keep `name`? Maybe useful for future use (like #4140)?
- I'm unhappy with the `Finished` line summary that displays `[unoptimized + debuginfo]`. It doesn't actually show what was compiled. Currently it just picks the base "dev" or "release" profile. I'm not sure what a good solution is (to be accurate it would need to potentially display a list of different options). Is it ok? (See also #4140 for the wrong profile name being printed.)
- Build-dependencies use different profiles based on whether or not `--release` flag is given. This means that if you want build-dependencies to always use a specific set of settings, you have to specify both `[profile.dev.build_override]` and `[profile.release.build_override]`. Is that reasonable (for now)? I've noticed some issues (like #1774, #2234, #2424) discussing having more control over how build-dependencies are handled.
- `build --bench xxx` or `--benches` builds dependencies with dev profile, which may be surprising. `--release` does the correct thing. Perhaps print a warning when using `cargo build` that builds benchmark deps in dev mode?
- Should it warn/error if you have an override for a package that does not exist?
- Should it warn/error if you attempt to set `panic` on the `test` or `bench` profile?
## TODO
- I have a long list of tests to add.
- Address a few "TODO" comments left behind.
Auto merge of #5415 - alexcrichton:rename-same-dep, r=matklad
Fix renaming crates as they come from 2 sources
Previously there was a verification in manifest parsing that the same dependency
must come from the same source, but this erroneously triggered an error to get
emitted when the `package` key was used to rename crates. The first change here
was to update that clause to key off the `rename` field rather than the `name`
field.
Afterwards, though, this exposed an existing bug in the implementation. During
compilation we have a `Resolve` which is a graph of crates, but we don't know
*why* each edge in the dependency graph exists. In other words we don't know,
when looking at an edge of the graph, what `Dependency` caused that edge to be
drawn. We need to know this when passing `--extern` flags because the
`Dependency` is what lists what's being renamed.
This commit then primarily refactors `Resolve::deps` from an iterator of package
ids to an iterator of a tuples. The first element is the package id from before
and the second element is a list of `Dependency` directives which caused the
edge to ber driven.
This refactoring cleaned up a few places in the backend where we had to work
around the lack of this knowledge. Namely this also fixes the extra test added
here.
Alex Crichton [Wed, 25 Apr 2018 17:41:33 +0000 (10:41 -0700)]
Fix renaming crates as they come from 2 sources
Previously there was a verification in manifest parsing that the same dependency
must come from the same source, but this erroneously triggered an error to get
emitted when the `package` key was used to rename crates. The first change here
was to update that clause to key off the `rename` field rather than the `name`
field.
Afterwards, though, this exposed an existing bug in the implementation. During
compilation we have a `Resolve` which is a graph of crates, but we don't know
*why* each edge in the dependency graph exists. In other words we don't know,
when looking at an edge of the graph, what `Dependency` caused that edge to be
drawn. We need to know this when passing `--extern` flags because the
`Dependency` is what lists what's being renamed.
This commit then primarily refactors `Resolve::deps` from an iterator of package
ids to an iterator of a tuples. The first element is the package id from before
and the second element is a list of `Dependency` directives which caused the
edge to ber driven.
This refactoring cleaned up a few places in the backend where we had to work
around the lack of this knowledge. Namely this also fixes the extra test added
here.
Auto merge of #5394 - henriklaxhuber:master, r=alexcrichton
Pass linker path to build script
This change adds the environment variable LINKER to pass the path of the linker used by cargo to the build script. This complements the variable RUSTC (the rustc binary used) to give the build script full knowledge of its environment.
A specific usage example would be automatically generating bindings to system headers in cross compilation, e.g. by locating jni.h for android targets.
Adds a target directory parameter, that acts in the same manner as the environment variable `CARGO_TARGET_DIR`, to the following subcommands:
- `bench`
- `build`
- `check`
- `clean`
- `doc`
- `package`
- `publish`
- `run`
- `rustc`
- `rustdoc`
- `test`
Auto merge of #5398 - dwijnand:drop-legacy-paths, r=matklad
Drop legacy path support under Rust edition 2018 (or later)
builds on #5335
submitted for early feedback: wdyt @matklad? is this what you had in mind? what should change? what should be added? how should we test this? is the current (2015) messaging enough to drop it in 2018?